Business Analyst Community & Resources | Modern Analyst

What is Thinking Outside the Box?

Adrian M. — Sun, 23 Nov 2025 22:30:00 GMT

Thinking outside the box is the ability to move beyond obvious or conventional solutions and reframe a problem so you can discover better options—while still staying grounded in business goals, constraints, and risks.

For a business analyst, that usually shows up in a few ways:

Challenging assumptions - Instead of accepting “this is how the process works,” you question why it’s done that way, what constraints are real vs. historical, and whether the original problem is even defined correctly.

Reframing the problem - You don’t just ask, “How do we build what the stakeholder requested?” You also ask, “What outcome are they really trying to achieve?” and “Is there a completely different way to achieve it?”

Looking across domains - You combine ideas from process improvement, UX, data, automation, and even policy changes. Sometimes the most effective solution is not a new system feature but a workflow change, a template, or a different handoff between teams.

Generating multiple, feasible options - Thinking outside the box isn’t random creativity; it’s structured. You use tools like root cause analysis, journey mapping, and “what if” scenarios to propose several viable alternatives, then help stakeholders evaluate them against value, cost, and risk.

For example, if sales asks for “a new weekly report” because they can’t track performance, an inside-the-box response is to design that report. Thinking outside the box might lead you to propose real-time dashboards, automated alerts when KPIs slip, and simplified data capture—addressing the visibility issue more effectively than the original request.

So, in summary, thinking outside the box as a BA is structured, outcome-focused creativity: challenging assumptions, reframing the problem, and exploring innovative yet practical options that deliver more value than the default solution.

What is the STRIDE technique for security analysis?

Adrian M. — Mon, 20 Oct 2025 00:31:00 GMT

STRIDE is a threat modeling framework developed by Microsoft to help identify and categorize potential security threats in software systems. It is commonly used during system design and architecture review to proactively uncover vulnerabilities before implementation or deployment.

1. Meaning of STRIDE

Each letter in STRIDE represents a type of security threat:

Letter	Threat Category	Description	Example
S	Spoofing	Impersonating another user, system, or process.	Logging in using someone else’s credentials.
T	Tampering	Modifying data or code, either in transit or at rest.	Altering a database record or configuration file.
R	Repudiation	Performing actions that cannot be traced or proven.	A user denies performing an operation because there is no audit log.
I	Information Disclosure	Exposing information to unauthorized entities.	Leaking personal data through logs or unsecured APIs.
D	Denial of Service (DoS)	Making a system or service unavailable to legitimate users.	Flooding a server with requests to crash it.
E	Elevation of Privilege	Gaining higher access rights than intended.	A normal user executes administrative commands.

2. Purpose and Benefits

STRIDE provides a structured approach for:

Identifying security risks early in the design phase.

Improving system resilience and compliance with security standards.

Facilitating communication among developers, analysts, and security teams.

It aligns with data flow diagrams (DFDs) — each DFD element (process, data store, data flow, external entity) can be analyzed against STRIDE categories to find relevant threats.

3. How STRIDE Works (Process)

Model the system: Create a Data Flow Diagram (DFD) or architecture diagram showing processes, data stores, data flows, and external entities.
Identify trust boundaries: Mark where different security privileges meet—these are high-risk areas.
Apply STRIDE categories: For each element in the DFD, ask STRIDE-based questions (e.g., “Can this data flow be tampered with?”).
Document threats: Log identified threats, their likelihood, and potential impact.
Mitigate and validate: Recommend and apply mitigations (authentication, encryption, logging, etc.), then validate the design.

4. Example

In a web application handling customer logins:

Spoofing: An attacker fakes a login token.

Tampering: JavaScript files are modified on the server.

Repudiation: No audit log of failed logins.

Information Disclosure: Passwords sent without encryption.

Denial of Service: Automated requests overwhelm the login endpoint.

Elevation of Privilege: A user manipulates a session to access admin features.

What Is Socio-Technical Architecture?

Adrian M. — Sun, 19 Oct 2025 22:38:00 GMT

In short, socio-technical architecture is the holistic design of how technology and people co-create value within an enterprise system. It ensures that the “architecture of the system” and the “architecture of the organization” evolve together.

For business analysts, this mindset elevates requirements work from specification to system stewardship—making sure that both the software and the people using it perform in harmony to achieve business outcomes.

What is Value Stream Mapping?

Adrian M. — Tue, 03 Jun 2025 03:51:00 GMT

Value Stream Mapping (VSM) is a Lean-origin technique that visually documents every step—people, processes, information flows, and wait times—required to deliver a product or service, from initial request to value in the customer’s hands. By showing both the current state and a desired future state, it highlights waste (non-value-adding activities) and improvement opportunities.

Key Elements Shown on a VSM

Process boxes – discrete activities with cycle time, change-over time, % complete & accurate.
Material or information flows – arrows indicating physical product movement or data transfer.
Queues & delays – inventory, backlogs, hand-offs, wait times.
Metrics bar – overall lead time, value-added time, first-pass yield, takt time.

Typical Mapping Steps (for a Business Analyst)

Define scope & customer value – choose an end-to-end slice (e.g., “loan origination” from application to funding).
Walk the Gemba – interview SMEs, observe real work to capture facts, not assumptions.
Draw the current-state map – use standard Lean symbols on paper or digital whiteboard.
Calculate totals – lead time vs. value-added time, identify bottlenecks.
Envision the future state – remove or streamline steps; realign flow to customer pull.
Create an action plan – prioritize improvements, assign owners, set measurable targets.

Why It Matters in Business Analysis

Clarifies end-to-end flow across silos, making hidden hand-offs visible.
Quantifies waste so business cases for change are evidence-based.
Aligns stakeholders on a shared visual artifact that transcends jargon.
Feeds requirements: future-state map becomes a source of epics, user stories, or feature backlog items.

VSM is not just a diagram; it’s a data-driven conversation starter that helps a BA turn qualitative pain points into quantified, prioritized improvements, accelerating delivery of customer value.

Example (Software Context)
In a mortgage software shop, mapping “borrower document upload to clear-to-close” might reveal 15 hand-offs, 3 manual re-key steps, and only 12 minutes of true value in a 4-day cycle. Consolidating document validation services and auto-notifications could cut lead time to <1 day and boost first-pass yield to 98%.

What is a Big Rock Project?

Adrian M. — Sun, 13 Oct 2024 00:04:00 GMT

A Big Rock Project is a large-scale initiative that plays a critical role in driving an organization’s long-term goals. These projects are strategically important and usually involve significant resource investment, high complexity, and a substantial impact on the organization’s future. Unlike regular projects, Big Rock Projects have clearly defined goals and high stakes, which means they require rigorous planning, broad stakeholder involvement, and formal governance. For example, a Big Rock Project could involve launching a major new product, implementing digital transformation, or expanding into a new market. These initiatives are crucial because they ensure the organization stays aligned with its strategic objectives and remains competitive.

The term "Big Rock" originates from a time management metaphor popularized by Stephen Covey, where the "big rocks" are the most important tasks that must be prioritized ahead of smaller, less critical activities.

Key Characteristics of Big Rock Projects

Strategic Importance - Big Rock Projects are aligned with the organization's mission and long-term objectives. They often drive transformative changes, such as launching a new product line, entering a new market, or implementing a major technological overhaul.

High Complexity and Scope - These projects are typically complex, involving multiple departments, stakeholders, and sometimes external partners. Due to their scope, they require careful planning and coordination.

Significant Resource Investment - Big Rock Projects demand considerable resources, including time, budget, and personnel, often spanning longer timeframes compared to regular projects.

High Impact and Risk - The outcomes of these projects can significantly influence the organization’s growth, profitability, and competitive positioning. Because of their scale, they also carry higher risks.

Defined Objectives and Non-Negotiables- Big Rock Projects have clear goals and success factors that are non-negotiable. Failing to meet these objectives can lead to substantial negative consequences for the organization.

Approach to Managing Big Rock Projects

Managing Big Rock Projects requires a more structured and disciplined approach compared to regular projects:

Upfront Planning - Extensive initial planning and requirements gathering are necessary to ensure all aspects are considered.

Stakeholder Engagement - Involve key stakeholders from various parts of the organization to ensure alignment and buy-in.

Risk Management - Proactively identify and mitigate risks due to the project’s scale and impact.

Formal Governance - Implement governance structures like steering committees to oversee progress and make strategic decisions.

What is an Architecture Decision Record (ADR)

Adrian M. — Sun, 08 Sep 2024 20:30:00 GMT

An Architecture Decision Record (ADR) is a structured document that records important architectural decisions made during the development of a system. It provides context, explains the rationale behind the decision, and outlines the potential consequences. ADRs help teams maintain a clear and consistent history of decisions, ensuring transparency and traceability throughout a project's lifecycle.

Key Components of an ADR:

Title: A short, descriptive name of the decision, summarizing the architectural choice.
Context: A detailed description of the problem or situation that necessitates a decision. It explains the background, including technical constraints, business goals, and other relevant factors.
Decision: A clear and concise statement of the decision that was made, outlining the direction the team will follow.
Alternatives: A summary of the different options considered. Each alternative should include pros and cons, as well as why it was ultimately not chosen. This demonstrates that multiple solutions were evaluated and thought through.
Consequences: The impact of the decision, including the trade-offs, risks, benefits, and long-term implications. It covers both positive and negative outcomes of the choice.
Participants: The names or roles of the people or teams who were responsible for making the decision. This ensures accountability and clarity regarding who has authority over key architectural choices.
Status: The current status of the decision, such as "Proposed," "Accepted," "Rejected," or "Superseded." It shows whether the decision is final or if it's subject to change.
Date: The date on which the decision was made. This helps establish a timeline for the decision-making process and provides context for when the choice was relevant.

Example ADR Template:

What is Cell-Based Architecture?

Adrian M. — Sun, 08 Sep 2024 19:47:00 GMT

Cell-Based Architecture is a decentralized system design approach where the system is broken down into small, independent units called "cells." Each cell functions autonomously, performing a specific task or service while having the capability to communicate and collaborate with other cells within the larger system. This architecture is highly modular, allowing for flexibility, scalability, and fault tolerance, which are critical in complex business environments.

The concept of cell-based architecture draws inspiration from a ship’s bulkhead design, where ships are divided into watertight compartments to prevent failure in one area from affecting the entire vessel. In a business context, this architectural style ensures system integrity by isolating potential failures, making it ideal for dynamic, distributed environments such as cloud systems, microservices, or large enterprise platforms.

Key Cell-Based Architecture Concepts for a Business/Systems Analyst:

Autonomy and Modularity - Each cell is self-contained, often with its own processing power and storage. This allows for easier maintenance and updates, as changes can be made to individual cells without disrupting the entire system. For a business analyst, this means greater agility in adapting systems to meet evolving business needs.

Scalability - Cells can be scaled independently based on demand. For instance, if a particular business function experiences high demand, only the relevant cells need to be scaled. This ensures efficient resource allocation and cost control, a key concern for system optimization.

Fault Tolerance and Reliability - Since cells operate independently, a failure in one cell doesn't bring down the entire system. This resilience is critical in business systems where uptime and reliability are essential to maintaining operations and minimizing risk.

Communication and Integration - Cells in the architecture are designed to communicate through well-defined interfaces, typically using APIs or messaging systems. This modular integration aligns with business analyst roles in ensuring that systems interact seamlessly, supporting cross-functional operations without dependencies on a monolithic structure.

Key Components of Cell-Based Architecture

Cell - A cell is the fundamental building block of cell-based architecture. It is an independent, self-contained unit that performs a specific function or set of tasks within the system. Each cell operates autonomously, with its own processing, storage, and network resources.

Cell Router - The cell router is responsible for directing requests to the appropriate cell within the architecture. It functions like a traffic controller, routing client requests or internal system communications to the right cell based on the nature of the request or service.

Control Plane - The control plane is responsible for managing and orchestrating the overall operation of the cell-based architecture. It oversees the lifecycle of cells (deployment, scaling, and destruction), monitors their health, manages communication, and enforces security and governance policies.

Inter-Cell Communication Layer - The inter-cell communication layer enables cells to communicate and exchange data with each other. Since cells operate independently, this layer facilitates the interaction between them, ensuring they can collaborate to complete tasks or share information without being tightly coupled.

What is Business Portfolio Analysis?

Adrian M. — Sat, 07 Sep 2024 18:17:00 GMT

Business Portfolio Analysis is a strategic tool used by companies to assess the performance and potential of various business units, products, or investments within their portfolio. The primary objective of this analysis is to determine where to allocate resources most effectively, identifying opportunities for growth, areas for improvement, or segments that should be divested.

Business portfolio analysis typically involves evaluating two key dimensions:

1. Market Attractiveness - This dimension refers to external factors like market growth rate, competitive intensity, and overall profitability potential within a given market. It helps companies understand which markets offer the best opportunities for growth and return on investment for the foreseeable future. This is the outward view.

2. Business Strength - This dimension considers internal factors, such as a company's competitive position, market share, financial performance, and ability to generate sustained revenue in a particular business area. This is the inward view.

One of the most commonly used tools for business portfolio analysis is the BCG Matrix (Boston Consulting Group Matrix), which categorizes business units or products into four groups based on their market growth rate and relative market share:

STARS - Business units with high market growth and high market share. These are often prioritized for further investment because they are leaders in expanding markets.

CASH COWS - Business units with low market growth but high market share. These are mature, profitable units that generate steady cash flow, which can be reinvested into other areas.

QUESTION MARKS - Business units with high market growth but low market share. These require careful consideration to determine whether they can be grown into Stars or if resources should be redirected elsewhere.

DOGS - Business units with low market growth and low market share. These typically underperform and may need to be divested or phased out to free up resources for more promising opportunities.

Other portfolio analysis frameworks, like the GE/McKinsey Matrix or SWOT Analysis, also help companies analyze different aspects of their portfolio based on market attractiveness, competitive strength, and strategic alignment.

What are the SOLID principles of architecture?

Adrian M. — Tue, 09 Apr 2024 02:56:00 GMT

The SOLID principles are a set of five design principles in software architecture and object-oriented programming that serve as guidelines for writing clean, maintainable, and scalable code. Each letter in SOLID stands for a different principle:

Single Responsibility Principle (SRP) - This principle states that a class should have only one reason to change, meaning it should have a single responsibility. This helps in keeping classes focused and makes the code easier to understand and maintain.

Open/Closed Principle (OCP) - The Open/Closed Principle states that software entities should be open for extension but closed for modification. This encourages designing software modules in a way that allows new functionality to be added without changing existing code.

Liskov Substitution Principle (LSP) - The Liskov Substitution Principle states that objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program. This promotes the use of inheritance and polymorphism while ensuring consistency in behavior.

Interface Segregation Principle (ISP) - The Interface Segregation Principle suggests that clients should not be forced to depend on interfaces they do not use. Instead of creating large interfaces with many methods, smaller and more specific interfaces should be preferred to promote loose coupling.

Dependency Inversion Principle (DIP) - The Dependency Inversion Principle states that high-level modules should not depend on low-level modules, but both should depend on abstractions. This encourages decoupling modules and promoting dependency injection, allowing for easier testing and flexibility in choosing implementations.

Overall, adhering to the SOLID principles helps in creating software that is modular, maintainable, and adaptable to changes in requirements and technology.

What is TOGAF?

Adrian M. — Tue, 13 Feb 2024 04:00:00 GMT

TOGAF stands for The Open Group Architecture Framework and is a widely used framework and methodology for enterprise architecture. It provides a comprehensive approach for designing, planning, implementing, and governing enterprise information technology architecture. TOGAF is maintained by The Open Group, a global consortium that develops open, vendor-neutral technology standards which help organizations to achieve their business objectives.

The main components and structure of TOGAF are as follows::

Architecture Development Method (ADM) - This is the core of TOGAF, providing a step-by-step approach for developing and managing enterprise architecture. It consists of a set of guidelines, techniques, and best practices for creating architecture artifacts and managing the architecture development process.

Guidelines & Techniques - This is a collection of best practices which will help the practitioners to adapt the TOGAF Architecture Development Method (ADM) to a number of usage scenarios. These guidelines and techniques include architecture principles, architecture patterns, gap analysis techniques, and much more.

Architecture Content Framework - This is a structured metamodel which defines the types of artifacts and deliverables that should be developed during the architecture development process, such as architecture vision, business architecture, data architecture, application architecture, and technology architecture. It also defines the concept of Architecture Building Blocks (ABBs) as well as Solution Building Blocks (SBBs)

Architecture Capability Framework - This section of TOGAF focuses on operationalizing an architecture function within an enterprise. It defines guidelines for establishing the structure, roles, skills, responsibilities needed for an effective architecture organization within the enterprise.

TOGAF Reference Models - These are generic architectural models and method guidance that can be used as starting points for developing organization-specific architectures. Examples of such models include Architecture Maturity Models, Architecture Project Management, Architecture Skills Framework, Digital Business Reference Model (DBRM), Government Reference Model (GRM), as well as Microservices Architecture.

Mirko Wolff, CC BY-SA 4.0, via Wikimedia Commons

An analyst can use TOGAF in several ways to support various aspects of enterprise architecture development and management:

Understanding Business Needs - Analysts can use TOGAF's Architecture Development Method (ADM) to analyze and document business requirements, stakeholder concerns, and strategic objectives.

Conducting Gap Analysis - TOGAF provides techniques for conducting gap analysis which analysts can use to assess the organization's current state, identify areas for improvement, and define target architectures that address business needs.

Supporting IT Initiatives - Analysts can use TOGAF to support various IT initiatives, such as system implementations, technology migrations, and business process improvements.

Communication and Collaboration - By using the common language and framework defined by TOGAF, analysts can facilitate communication and collaboration among stakeholders, including business leaders, IT professionals, and external partners.

What is a Reliability Block Diagram (RBD)?

Adrian M. — Mon, 12 Feb 2024 06:22:00 GMT

A Reliability Block Diagram (RBD) is a graphical method used in reliability engineering to model the reliability of systems. It represents the components of a system as blocks and their interconnections as lines. The purpose of an RBD is to analyze and understand the reliability of a system by assessing how the failure of individual components or blocks affects the overall reliability of the system.

Reliability Block Diagrams (RBDs) can be relevant to both business and systems analysts, particularly in industries where system reliability is critical, such as manufacturing, transportation, telecommunications, and energy.

What is Composable Business Architecture?

Adrian M. — Sun, 10 Sep 2023 22:50:00 GMT

Composable Business Architecture (CBA) is a business architecture approach and methodology that emphasizes flexibility, adaptability, and modularity in designing and organizing the components of a business. It is a response to the ever-changing and complex nature of the business environment, where organizations need to be agile and responsive to rapidly evolving market conditions and customer demands.

“Composable business means creating an organization made from interchangeable building blocks” - Kasey Panetta, Gartner Contributor

The same way a Lego brick is the basic building block of any Lego masterpiece, a Packaged Business Capability (PBC) is the basic building block of a composable business model. Each of the enterprise PBCs fulfills a critical function of the business.

“Composable business is a natural acceleration of the digital business that you live in every day. It allows us to deliver the resilience and agility that these interesting times demand.” - Daryl Plummer, Distinguished VP Analyst, Gartner.

Gartner identifies, four principles of composable business architecture:

Modularity - dividing the business domain into smaller discrete components with clearly defined responsibilities

Autonomy - ensure the individual components are as independent as possible from other components in order to minimize dependencies and enterprise impact when one component needs to be changes or replaced

Orchestration - the process and tools used to control the flow and collaboration among the individual business components in order to achieve specific business objectives

Discovery - the ability to easily find and understand existing business process and component assets within the enterprise to facilitate reusability and for quickly composing new processes for in response to opportunities or business landscape changes

“An organization that delivers business outcomes and adapts to the pace of business change. It does this through the assembly and combination of packaged business capabilities… application building blocks that have been purchased or developed.” — Gartner

When it comes to establishing composable businesses, Gartner defines three essential building blocks, as follows:

Composable thinking - Composable thinking is an adaptable problem-solving approach that involves breaking complex challenges into modular components, allowing for flexible and creative recombination to address evolving needs, fostering innovation and efficiency. It emphasizes modularity, reusability, and customer-centricity in finding solutions and is relevant across diverse domains, including technology, business, and product development.

Composable technology - Composable technology refers to an IT infrastructure and architecture approach that leverages modular components and software-defined resources, enabling organizations to dynamically and flexibly allocate computing, storage, and networking resources to meet specific application or business requirements. This approach enhances agility, scalability, and resource utilization in a rapidly changing technology landscape, allowing organizations to adapt quickly to evolving needs and opportunities.

Composable business architecture - Composable Business Architecture is a strategic framework for designing and organizing a business's components, such as processes, capabilities, and technologies, in a modular and flexible manner. It enables organizations to quickly adapt to changing market conditions, customer demands, and emerging opportunities by promoting modularity, reusability, and interoperability in their business operations.

Composable Business Architecture is particularly relevant in industries characterized by rapid change, digital transformation, and the need for continuous innovation. It helps organizations stay competitive and responsive to emerging opportunities and challenges by providing a framework for designing and organizing their business components in a flexible and adaptable manner.

What is Business Architecture?

Adrian M. — Sun, 09 Jul 2023 01:48:00 GMT

Most of us are familiar with the term architecture… The first thing that comes to mind is a specific building or structure. In this context, architecture refers to the practice of careful design and building of the various components, and their integration, that make up the given structure.

Very similarly, business architecture is the deliberate design, organization, and building of an organization designed for a given purpose.

The Object Management Group (OMG) defines Business Architecture as follows:

“The structure of the enterprise in terms of its governance structure, business processes, and business information. In defining the structure of the enterprise, business architecture considers customers, finances, and the ever-changing market to align strategic goals and objectives with decisions regarding products and services; partners and suppliers; organization; capabilities; and key initiatives.”

In other words, business architecture refers to the deliberate and organized structure of the various business components and the relationships and interactions between them.

What is the difference between business architecture and system architecture?

System architecture deals with the design and implementation of an information system in terms of the various system layers (ex: data storage layer) and the respective components (ex: databases, data feeds, data transformations, etc.). Similarly, the business architecture deals with the various business areas (ex: finance) and the respective components (ex: accounts payable, accounts receivable, payroll, etc.)

What are some examples of business architecture components?

Just as there are many ways of representing system architecture, there are many ways of model and express business architecture.

Some of the more common elements of a business architecture are:

Capabilities

Value Streams

Products or Services

Processes

Business Rules and Policies

Organization (people, departments)

Customers

Partners & Vendors

Strategy

What are the benefits of business architecture?

The definition and deliberate design of business architecture provides many benefits to an organization, including:

Alignment - Business architecture aligns business strategy with the organization's operations, ensuring that all aspects of the business are working towards common goals.

Clarity - Business architecture provides a clear and shared understanding of how the organization operates, enabling effective communication and decision-making.

Change Management - Business architecture helps organizations plan and manage change initiatives by providing the foundation upon which to build new strategies, processes, or technologies.

Optimization - Business architecture enables the organization to identify inefficiencies, redundancies, and areas for improvement within their operations..

Integration - Business architecture enables the integration of new systems, technologies, products, or services into the existing business ecosystem.

Risk Management - Business architecture helps identify and mitigate risks by understanding dependencies, vulnerabilities, and potential impacts on the organization's operations.

What is a Concept Model?

Adrian M. — Mon, 09 Jan 2023 03:04:00 GMT

A concept model is a business analysis model whose purpose is to depict the core concepts of the problem or solution domain being studied. At its core, it consists of the clear definition of the terms (nouns and verbs) which are important to the organization or the given domain.

Depending on the need and the experience of the business analyst, the concept model would be made up of a visual representation of the model, definitions of each concept in the model, as well as the model structure showing the relationships among the concepts.

The IIBA BABOK Guide Glossary defines the concept model as follows:

“An analysis model that develops the meaning of core concepts for a problem domain, defines their collective structure, and specifies the appropriate vocabulary needed to communicate about it consistently.”

Elements of a Concept Model

In a comprehensive concept model, there are a number of different types of elements:

Nouns - These are the key “entities” or “classes” of the domain being considered. For example, for a banking system, the nouns in the concept model might include: account, customer, transaction amount.

Verbs - These are the key action terms which define the relationships among noun concepts. For example, for a banking system, the verbs in the concept model might include: deposit, withdraw, create. This results in relationships such as: customer deposits transaction amount, customer opens account, etc.

The Purpose of a Concept Model

The goal of the concept model is to enable the mutual understanding and communication of key concepts among all the project participants and stakeholders. The concepts defined in the model are then able to be consistently used when discussing project requirements, defining business rules, training new users, and much more.

Concept Model Representation

There are many ways and tools which can be used to create a concept model:

UML Class Diagram
Data Dictionary/Glossary
Entity Relationship Diagram
Ontology Definition Metamodel (ODM)
Concept Map

Having a concept model is often more important than the exact method of representing the model. It is better to start with a simple list of terms, a basic glossary, and then expand and refine the model as dictated by the needs of the project or organization.

What’s the difference: On-Premise vs Cloud vs. Fog vs. Edge Computing?

Adrian M. — Mon, 10 Oct 2022 20:03:00 GMT

Before we jump into the comparison of on-premise vs. cloud vs. fog vs. edge computing we need to take a step back and use first principles thinking by first defining the terms in a stepwise manner.

Let’s start with what is computing? For our purposes, let’s keep it simple: it’s the activity or process performed by computing devices (hardware or software) in order to achieve a specific goal or objective. The types of computations very drastically but can include activities such as retrieving data, performing searches, executing algorithms, or making decisions.

The key difference between on-premise vs. cloud vs. fog vs. edge computing has to do with where the computing takes place.

What is the Abilene Paradox and its impact to projects?

Adrian M. — Mon, 11 Jul 2022 03:06:00 GMT

The Abilene Paradox is that phenomenon which occurs when a group of people make a decision together which is counter to what the majority of the individuals or the group actually think or want.

It's an example of negative groupthink and communication breakdown which occurs when individual members of the group believe that their own opinion or preference is counter to what the group wants, without realizing that others are thinking the same way.

The Abilene Paradox can occur in the most polite and civil environments where each group member may mistakenly assume that the group wants and chose to not raise any objections in order to not "rock the boat".

This phenomenon was first introduced by Jerry B. Harvey in an article titled "The Abilene Paradox: The Management of Agreement". Oddly enough, what Harvey noticed is that this occurs when the group is ineffective at managing agreement. Unlike managing disagreement when a group can't figure out how to come to a resolution or compromise, the Abilene Paradox occurs when individual members of a group do not raise concerns about the group decision even though, deep down, they do not agree with it.

So how can the Abilene Paradox impact your project?

Imagine a business analyst, on a large software development project, simply jotting down a critical decision or important requirement decided by a group of stakeholders against common sense and against the individual stakeholders judgement and expertise. Imagine that requirements is now implemented and deployed to production only to find out that's not what anybody wanted.

If you had the feeling and thoughts that it's the wrong decision, would you go against the grain and raise your hand?

Do you have what it takes to question the expertise of the subject matter experts?

How can you spot and avoid falling in the trap of the Abilene Paradox?

Avoiding the Abilene Paradox

As a business analyst, you need to recognize that agreement is not always good - especially when the problem is complex yet the agreements develops very quickly. Before we can avoid it, we must first understand why the Abilene Paradox occurs. Here are a some of the reasons:

Fear of being wrong - what if my idea is a bad one?

Fear of rejection - what if they don't like my idea?

Laziness to fight for a point of view - well, if that's what everybody wants, it's fine with me?

Fear of conflict - the team is working so well together, I don't want to be the one causing conflict?

To avoid falling into the Abilene trap, the business analyst should:

Look for and recognize when complex decisions are made in record time without disent.

Have one-on-one conversations with individuals from the group to get their opinion on the decision

Ask the group: "What would others think of this decision?"

Ask the group: "Do you see any issues with this decision?"

Encourage open communication to ensure everyone's opinion is heard.

Reward and recognize dissenting opinions and thoughts.

What is the difference between IIBA BABOK tasks "Specify and Model Requirements" and "Define Solution Options", 2 of the 6 tasks covered within the “Requirements Analysis and Design Definition” knowledge area?

Chris Adams — Thu, 09 Jun 2022 21:13:00 GMT

The Specify and Model Requirements Task describes the “What”.

The Define Solution Options Task describes the “How”.

What are the Business Analysis Knowledge Areas?

Chris Adams — Tue, 07 Dec 2021 20:56:00 GMT

This question is an easy way for a hiring manager or an HR professional to screen out candidates who may have under-invested in their career or may lack understanding of the business analysis profession. The 6 Knowledge Areas are:

Elicitation & Collaboration
Requirements Analysis & Design Definition
Solution Evaluation
Requirements Life Cycle Management
Business Analysis Planning & Monitoring
Strategy Analysis

What is Enterprise Architecture?

Chris Adams — Sun, 06 Dec 2020 19:00:00 GMT

Enterprise Architecture was born out of the world of Information Technology and comprises Application Architecture, Data Architecture, and Infrastructure Architecture. As more professionals focus on the related topic of Business Architecture -- which covers the business organizational structure, business capabilities, business value streams or business processes, business knowledge, and finally the business strategy -- the need to clearly articulate the relationship between Enterprise Architecture and Business Architecture grows. however, practitioners and leaders in the field have begun to broaden the definition of Enterprise Architecture to also include Business Architecture as a fourth sub-component, leaving Enterprise Architecture as the overarching concept.

How would you build a Business Process Model?

Chris Adams — Mon, 09 Nov 2020 03:31:00 GMT

Building a Business Process Model is a complex task that requires a number of successful steps to complete.

1) Determine scope

2) Gather background information

3) Conduct interviews

4) Begin Modeling

5) Validate and iterate

What is DMN and how is it used to support BPMN?

Chris Adams — Sun, 11 Oct 2020 17:35:00 GMT

BPMN is used to define business processes as a sequence of activities. Gateways are used to show branching of different process paths. For many years, analysts would clumsily model decision logic directly in business process models in an attempt to fully define process branching logic. This made process models messy.

DMN or Decision Modeling Notation was published in 2015 by the Object Management Group. It's a graphical language for specifying business decisions. DMNs primary purpose is to give analysts a tool for separating the business decision logic from the business process.

Is it really necessary to document the business vision at the start of a project?

Chris Adams — Mon, 08 Jun 2020 16:55:00 GMT

The business vision serves as a foundation that drives, guides and unifies the project from beginning to end. It may be captured in a 1-page Vision statement or a formal Vision document, depending on the size and complexity of the project.

When aligning your enterprise with a defined business strategy, what key aspects ensure that you can deliver real business value?

Chris Adams — Mon, 13 Jan 2020 01:04:00 GMT

Aligning your enterprise with a defined business strategy is what enterprise business architecture is all about. It's critical to organizational survival. Sharing business knowledge with all stakeholders is indispensable and necessary in order to align the goals and strategy of the business across all aspects of the organization. True business value is generated through effective alignment.

Enterprise business architecture boils down to four key aspects of organizational alignment:

What is Enterprise Architecture, and why is it relevant to a Business Analyst?

Chris Adams — Sun, 08 Dec 2019 17:00:00 GMT

Enterprise Architecture (EA) is the practice of fully describing and viewing an enterprise through the use of models and other representations. EA’s views of the enterprise cut across all of the domains that a complex enterprise contains: security, strategy and performance, business, data, infrastructure, and applications.

What is PEST Analysis?

Chris Adams — Sun, 12 May 2019 14:59:00 GMT

PEST is an acronym that stands for Political, Economic, Social, Technological. PEST analysis is one way that a business can analyze the environment in which it operates.

What is Business Capability Mapping and why it is beneficial?

Chris Adams — Mon, 12 Nov 2018 19:13:00 GMT

Business capability mapping depicts what a business does to reach its strategic objectives (its capabilities), rather than how it does it (its business processes). Business capabilities are the connection between the business strategy and business execution.

How is the Purpose Alignment Model used to prioritize requirements?

Chris Adams — Mon, 12 Nov 2018 16:00:00 GMT

The Purpose Alignment Model aids in prioritizing requirements and guiding investment decisions by rating requirements (which may be capabilities, processes or tasks) along two dimensions:

whether it creates market differentiation or contributes to the value proposition
whether it is critical for ongoing operation of the organization

What is a Business Architect and is it different from a Business Analyst?

Chris Adams — Fri, 07 Sep 2018 16:35:00 GMT

The term Business Analyst is broad. The name alone implies that a business analyst performs some form of business analysis, but that’s not very specific.

When using the term business analyst broadly it may in fact be describing any number of more specialized roles, including:

Business Process Engineers
Product Managers
Systems Analysts
Requirements Engineers
Financial Analysts
Business Architects
Usability Analysts
Data Analysts
etc.

In comparison, a Business Architect focuses on the activity of creating and managing the business architecture. So what is a business architecture exactly?

How does Enterprise Analysis bring value to an organization?

Chris Adams — Sun, 13 May 2018 21:43:00 GMT

The information produced through Enterprise Analysis is the basis for critical project decisions – what the project is expected to cost, what value it is expected to bring, whether any solution can be reasonably expected to address the business needs, which solution is the ‘best’ when alternatives are available, and the ultimate decision- should the organization even proceed with a particular project or course of action.

What is Gap Analysis?

Chris Adams — Sun, 13 May 2018 21:39:00 GMT

Gap Analysis is the process of comparing two things in order to determine the difference or “gap” that exists between them. Once the gap is understood, the steps required to bridge the gap can be determined.

What is the different between a business policy and a business rule?

Chris Adams — Sun, 12 Feb 2017 11:52:00 GMT

Business Rules and Business Policies tend to be complicated for analysts to untangle because they are so closely related. Policies are typically more general assertions or guidance about how an organization is intended to operate, while business rules describe the specific execution of the business policy.

The BABOK describes a policy as “a non-actionable directive that supports a business goal', and a business rule as 'a specific, actionable, testable directive that is under the control of the business and supports a business policy'

The Business Rules Group goes further in their definition of business rules describing it as an atomic statement that defines or constrains some aspect of the business. They categorize business rules as one of three sub-classifications; structural assertion, action assertion, or derivation. The definitions of these get quite detailed and while knowing them, along with understanding things like fact models, may help elaborate one’s understanding of a business rule, at a summary level business rules are best understood by a higher level definition (like the IIBA’s) and a few examples.

Additionally, policies, being more general, typically change less often than business rules which are specific implementations of policies.

To restate, a policy is:

A non-actionable directive
Often requires employees to translate into specific statements of what to do (business rules)
Supports a business goal
Supported by one or more business rules

A business rules is:

Actionable
Specific
Testable
Supports a policy

Examples of policies for a car rental company:

Maintenance must be performed in a manner which maximizes the life and value of the car
Renters must have valid insurance

Example of business rules that may support these policies:

All vehicles are required to have a 58 point inspection after every 3 months of use before re-renting.
A car which has accumulated more than 3500 miles must have its oil changed before re-renting.
Tires with less than 1/16th inch of tread must be replaced.
Renters in the state of Texas must have insurance covering $100,000 of liability or more.
Renters in the state of Arizona must have insurance covering $50,000 of liability or more.

Notice that each of the business rules are written as a level which is actionable, specific, and testable.

--
Chris Adams
LinkedIn Profile

What is a Fact Model?

Chris Adams — Sat, 12 Mar 2016 18:00:00 GMT

A Fact Model is a static model which structures business knowledge about core business concepts and business operations. It is sometimes called a business entity model.

PEST Analysis to PESTLE Analysis, what is the difference?

Chris Adams — Mon, 09 Nov 2015 21:45:00 GMT

PESTLE analysis extends the original PEST analysis, by analyzing the Legal and Environmental factors that may influence a business.

What is RML (Requirements Modeling Language)?

Chris Adams — Sun, 10 May 2015 23:02:00 GMT

Requirements Modeling language is a collection of diagrams used to model software from the business analysis or product management perspective.

What is a balanced scorecard?

Chris Adams — Sun, 12 Oct 2014 19:29:00 GMT

A balanced scorecard is a framework that organizations can use to align business activities to the organization’s strategy and vision. Although often viewed as a strategic tool, the balanced scorecard works equally well at the operational level.

How can software projects contribute to the organization’s balanced scorecard?

Chris Adams — Sun, 12 Oct 2014 19:23:00 GMT

The planning process for software projects typically involves the identification of target-state goals and objectives to be achieved. These goals can be aligned to the organization’s strategic and operational goals, and project metrics can be set within each of the balanced scorecard perspectives.

What is Cloud Computing and what are the pros and cons?

Chris Adams — Sun, 09 Sep 2012 16:12:00 GMT

Cloud computing is the use of internet-based services to store, manage, and process data in order to provide applications and services to users. Cloud computing can be categorized into three areas:

Infrastructure-as-a-service (IaaS) – vendors provide the physical data centers and network hardware. Typically clients will pay based only on the amount of resources they use.

Platform-as-a-service (PaaS) – a delivery model in which the consumer creates the software using the tools, libraries, and preconstructed services from the provider while maintaining control over the configuration and deployment of the software.

Software-as-a-service (SaaS) – a software delivery model in which the software, and usually the data, is provided by the vendor and hosted “in the cloud”. Vendors run the software application for you. The software can be seamlessly and continually updated.

Cloud computing has both pros and cons to consider

The Pros:

Reduced Set Up Costs - Cloud computing minimizes large upfront investment in hardware and software. Additionally, it decreases the need for IT staff to maintain the hardware and software. Some staff are often still needed but on a dramatically smaller scale. Cloud computing distributes the cost of expensive hardware and software across many smaller companies.

Scalability - Cloud services are readily scalable to meet the needs of the client with clients paying for resources as they are needed (usually following a tiered pricing structure). With auto- scaling (elastic) services, clients can often receive real-time scaling with no additional action necessary.

Lower Barriers to Entry - Cloud computing gives small and mid-size businesses access to the types of infrastructure and sophisticated technology that previously would have required the deep pockets of a big corporation.

Limited Need for Expertise - Cloud computing in most cases limits the need to hire technology or security experts. Given the relatively new nature of Infrastructure as a Service, some expertise is still warranted to ensure that servers and nodes stay up and running, but certainly less than what would have previously be needed. As you move towards Software as a Service almost no expertise is required.

Collaboration - Cloud computing offers software and services that can be accessed by any computer, anywhere, anytime. This improves the collaboration that can be achieved by distributed teams and organizations in a global workforce.

The Cons:

Lack of Availability - Cloud service and infrastructure can still go down. If it does, your organization can be left without important information or software for hours.

Data Ownership and Exchange - If your organization stops using a cloud software or service, can you retrieve all of the data that you have accumulated over time? Additionally, can you be sure that the provider of the software or service has properly disposed of your data?

Privacy and Control - What is the service provider doing with your data? Are they protecting the data or are they collecting it and using it for other purposes for their gain?

Explain Kurt Lewin’s Model of Organizational Change

Chris Adams — Sun, 13 Mar 2011 22:21:00 GMT

If there is one thing that you can be certain of in business today it’s change. Kurt Lewin, a physicist and social scientist, defined a model for organizational change as far back as 1947. This model is still taught today in many business schools as part of the change management discipline.

Lewin used an analogy of changing the shape of a block of ice to convey his theory. If you want to change the shape of a block of ice you must first melt it or break down its existing structure. Once it’s unfrozen, it becomes liquid and can be changed by guiding it in any direction you desire. Using a mold, you can cause it to take on a different shape from its original state. Finally, you freeze the liquid within the mold to crystallize it into its new shape. This is how Kurt Lewin explained his influential three-stage model of organizational change. Here are some key points to consider when thinking about three stages of change (Unfreeze, Change, Freeze).

Unfreeze

Before you can begin changing an organization in any meaningful way you need to overcome the inertia of the existing way of doing things. This starts by challenging many of the beliefs, attitudes, and behaviors of people within the organization. As Lewin put it, “Motivation for change must be generated before change can occur. One must be helped to re-examine many cherished assumptions about oneself and one’s relations to others.” You are breaking down the status quo. During the unfreezing process everyone feels that things are becoming off balance. This feeling becomes a strong motivator for people to seek out a new equilibrium. During this stage, you need to sell the benefits of the change. The more people that recognize that the change needs to occurs the more likely it will be successful.

Determine what needs to change
Sell the benefits of the change to everyone involved (this includes getting support from upper management)
Specifically address any doubts or concerns

Change

Once the organization has gone through the unfreeze stage, effective change can begin within the organization. People begin to look for new ways to do things and support the new direction. Time and frequent communication are two key factors for the change to occur. People need to understand the changes as they occur and feel that they are part of the change. Some take a long time to recognize the real benefits. This can lead to fear and rumors that need to be handled quickly.

Involve people in the process and empower them
Communicate frequently
Dispel rumors quickly

Freeze

Once the changes have taken effect, the next stage is to freeze or crystallize the changes within the organization. Putting the proper processes and the organizational hierarchy in place to manage them is important to ensure this happens. Since change is always occurring, some might ask why bother to freeze things. Why not stay in a constant state of change? Constant change, without freezing things in place at least momentarily, leaves people without a clear sense of direction. It becomes more and more difficult as time goes on to convince people that something needs changing if you don’t give the most recent changes time to fully crystallize. Also, taking the time to celebrate the successful completion of changes within the organization provide everyone with a feeling of reward and gives them closure.

Develop processes to anchor the changes into the culture
Provide clear communications, support and training
Celebrate the successful completion of changes

--
Chris Adams
LinkedIn Profile

When performing Cost-Benefit Analysis using discounted cash flows, how do you select and appropriate discount rate?

Chris Adams — Sat, 03 Apr 2010 18:24:00 GMT

Cost-Benefit Analysis (CBA) is a critical activity in the work of a business analyst. While many business analysts may be brought onto a project well after this activity has occurred, nearly all projects which require a large amount of resources (time, people, or money) are assessed based on the CBA of the project. The activity is typically performed by a business analyst, often one specializing in the area of financial analysis, though any business analyst can learn this straightforward activity.

The most prominent and well known aspect of CBA is Discounted Cash Flow (DCF) analysis which discounts future cash flows (both negative and positive) using a Discount Rate to arrive at a Net Present Value (NPV). This is represented by the following equation.

NPV = (FVpos – FVneg) / [(1 + i)^t]

where,

NPV = Net Present Value
FVpos = Future Value of a Positive Cash Flow at “t” years
FVneg = Future Value of a Negative Cash Flow at “t” years
i = Discount Rate
t = time (years from present)

Future cash flows are discounted using a Discount Rate (i) that is chosen to accurately reflect several factors:

Time Preference – The theory that a person or institution would rather have money in hand now to spend on immediate wants or needs rather than waiting for future cash flows.
Interest – Accounts for the fact that a person or institution that doesn’t receive money for several years also loses the opportunity to gain interest on the money for that period of time.
Risk Premium – Reflects the additional return that a person or institution requires on later cash flows to account for the risk of future payments not materializing.

While the Discount Rate used for DCF calculations will vary, it becomes clear that the discount rate should be larger than any single factor above. If the interest that can be attained on the money that is being tied up is %5 per year, the discount rate should certainly be higher than 5% to account for Time Preference and the Risk Premium.

How is the Enterprise Analysis knowledge area of the BABOK v2.0 defined?

Chris Adams — Sat, 03 Apr 2010 18:22:00 GMT

The Enterprise Analysis knowledge area includes 5 BABOK tasks:

Define Business Need
Access Capability Gaps
Determine Solution Approach
Define Solution Scope
Define Business Case

The purpose of the Enterprise Analysis knowledge area is to describe the business analysis activities required to compare the needs of the business against the current capabilities of the business and identify opportunities for improvement. Then, based on this information, the analyst can determine which solutions should be selected to resolve the issue. The output of this knowledge area provides helpful background information for the Requirements Analysis knowledge area as well as the Solution Assessment and Validation knowledge area. The work done during Enterprise Analysis is also helpful for long term strategic planning as it paints a picture of the current state and capabilities of the business.

Before any new project is started, analysts and business stakeholders should understand how the project goals and objectives fit into the overall direction and plan for the enterprise. Without the Enterprise Analysis activities this wouldn’t be possible.

What is a View as it relates to system modeling?

Chris Adams — Sat, 09 May 2009 22:06:00 GMT

What is the 4 +1 View Model as it relates to system modeling?

Chris Adams — Sat, 09 May 2009 21:59:00 GMT

The 4 + 1 View Model is a predefined set of views for organizing the design and architecture of a system. It was developed in 1995 by Philippe Kruchten, formerly the Director of Process Development at Rational Software.

The 4 + 1 View Model gets its name from the 4 primary views and 1 supporting view that are used to capture and communicate different aspects of the system.

The 4 primary views are:

Logical View: this view describes the functionality of the system in terms of its static structure and dynamic behavior.
Development View: this view describes the system from a programmer’s perspective and is concerned with the organization of physical code, its main modules, and their dependencies.
Process View: this view focuses on the runtime behavior of the system and the elements of the system that relate to process performance. It includes aspects important to scalability, throughput, and process response times to name a few.
Physical View: this view shows the system from a system engineer's point-of-view. It is concerned with the deployment of software components across the physical architecture including computers and devices , as well as communication between these components.

The 1 supporting view is:

Use Case View: this view describes the functionality of the system from the perspective of external actors.